The Design of RPM: An FPGA-based Multiprocessor Emulator

As the complexity of the examined systems increases and as the data set sizes of the typical application programs grow, it becomes more and more difficult to simulate these systems in detail. Architecture simulators which typically model a system at a very abstract level may take several hours to simulate a second of the execution of the target system , while detailed cycle-by-cycle simulators are usually much slower. RPM is an unique tool that bridges the gap between simulation and prototyping of multiprocessor systems through hardware emulation. RPM has a slowdown factor in the order of hundreds whereas simulators have a slowdown factor of tens of thousands with respect to a target system. Since every emulation is an actual incarnation of the target system, RPM emulations are much more detailed than typical simulation models, providing valuable insight into the design of the target system. RPM utilizes FPGAs in the controllers at all levels of the memory hierarchy and uses off-the shelf components for the rest of the system. This feature makes it possible for RPM to emulate various multiprocessor systems, including CC-NUMA architectures, COMAs, Message-Passing Systems , and Virtual Shared Memory Systems. Many different hardware mechanisms for these systems can also be implemented. Moreover, RPM is able to run realistic workloads such as operating system kernels, database engines, and multitasked scientific workloads with the real data set sizes for which the target machine is built. SRAM are removed from the addressing space and MC1 is signalled to start responding to instruction fetches and normal data accesses as well as test mode accesses. As soon as all boards have switched to emulation mode the emulation of the target architecture begins. The program loaded by the I/O board has been linked with all required libraries as well as a basic run-time system. The program contains start/stop macros to control the mechanism for performance statistic collection. After the execution of the program is finished, every PE waits while the I/O board uploads the results and the collected performance statistics to the host computer. The SCSI protocol between the I/O board and the host workstation is master/slave, the workstation being the master. In other words, only the host workstation can initiate SCSI transactions. To allow RPM to initiate the communication when necessary an extra RS-232 connection has been added between the host and the I/O board. RPM can also operate in stand-alone or debugging …